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Long Term Evolution (LTE) is the latest buzzword on everyone's lips, but are you as 
conversant with the LTE architecture as you would like to be, or — more importantly — 
need to be? Would you like to find out more about LTE, but have little time to devote 
to it? If so, this paper will help get you up to speed in no time. Originally published as a 
chapter in the most comprehensive LTE reference book available, LTE — The UMTS Long 
Term Evolution: From Theory to Practice (Wiley 2009), this paper provides a short, but 
comprehensive, overview of the 3GPP Release 8 LTE network architecture and interfaces, 
showing how it can be deployed in an optimized and efficient manner. Engineers involved 
in the design of LTE interfaces and network equipment, as well as those involved in the 
first deployments of this new technology, should find this paper invaluable. 
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1 . Executive summary 

This paper provides a comprehensive overview of the network architecture of a Long Term Evolution 
(LTE) system according to the Release 8 version of the specifications. It is designed to enable the reader 
to become conversant rapidly with the main principles of the LTE network architecture. Engineers 
involved in the design of LTE interfaces and network equipment, as well as those involved in the first 
deployments of this new technology, should find this paper invaluable. 

Not only does this paper provide a straightforward introduction to the definitive but complex speci- 
fications defined by the Third-Generation Partnership Project (3GPP), but it also particularly high- 
lights aspects of the network architecture and interfaces that enable LTE networks to be deployed in 
an optimized and efficient manner. References are provided throughout so that the interested reader 
can readily access more detailed material. 

The content of this paper, authored by Sudeep Palat and Philippe Godin, was originally published 
as an invited chapter in the book LTE — The UMTS Long Term Evolution: From Theory to Practice 
(Wiley 2009), edited by Stefania Sesia, Issam Toufik and Matthew Baker, which is widely recognized 
as the most comprehensive reference book available on LTE. Sudeep Palat, Philippe Godin and 
Matthew Baker are all lead representatives in Alcatel-Lucent’s 3GPP standardization team. 


2. Introduct ion 


In contrast to the circuit-switched model of previous cellular systems, Long Term Evolution (LTE) 
has been designed to support only packet-switched services. It aims to provide seamless Internet 
Protocol (IP) connectivity between user equipment (UE) and the packet data network (PDN), 
without any disruption to the end users’ applications during mobility. 

While the term “LTE” encompasses the evolution of the Universal Mobile Telecommunications 
System (UMTS) radio access through the Evolved UTRAN (E-UTRAN), it is accompanied by an 
evolution of the non-radio aspects under the term “System Architecture Evolution” (SAE), which 
includes the Evolved Packet Core (EPC) network. Together LTE and SAE comprise the Evolved 
Packet System (EPS). 

EPS uses the concept of EPS bearers to route IP traffic from a gateway in the PDN to the UE. 

A bearer is an IP packet flow with a defined quality of service (QoS) between the gateway and the UE. 
The E-UTRAN and EPC together set up and release bearers as required by applications. 

This paper provides a comprehensive tutorial of the overall EPS network architecture, giving an 
overview of the functions provided by the core network (CN) and E-UTRAN. The protocol stack 
across the different interfaces is explained, along with an overview of the functions provided by the 
different protocol layers. The end-to-end bearer path along with QoS aspects are also discussed, 
including a typical procedure for establishing a bearer. The remainder of this paper presents the 
network interfaces in detail, with particular focus on the E-UTRAN interfaces and the procedures 
used across these interfaces, including those for the support of user mobility. 

3. Overall architectural overview 

EPS provides the user with IP connectivity to a PDN for accessing the Internet, as well as for running 
services such as Voice over IP (VoIP). An EPS bearer is typically associated with a QoS. Multiple 
bearers can be established for a user in order to provide different QoS streams or connectivity to 
different PDNs. For example, a user might be engaged in a voice (VoIP) call while at the same time 
performing web browsing or FTP download. A VoIP bearer would provide the necessary QoS for the 
voice call, while a best-effort bearer would be suitable for the web browsing or FTP session. 
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The network must also provide sufficient security and privacy for the user and protection for the 
network against fraudulent use. 


Figure 1. The EPS network elements 



This is achieved by means of several EPS network elements that have different roles. Figure 1 shows 
the overall network architecture, including the network elements and the standardized interfaces. 
At a high level, the network is comprised of the CN (EPC) and the access network E-UTRAN. 
While the CN consists of many logical nodes, the access network is made up of essentially just one 
node, the evolved NodeB (eNodeB), which connects to the UEs. Each of these network elements 
is interconnected by means of interfaces that are standardized in order to allow multi-vendor 
interoperability. This gives network operators the possibility to source different network elements 
from different vendors. In fact, network operators may choose in their physical implementations 
to split or merge these logical network elements depending on commercial considerations. The 
functional split between the EPC and E-UTRAN is shown in Figure 2. The EPC and E-UTRAN 
network elements are described in more detail below. 


Figure 2. Functional split between E-UTRAN and EPC 
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3.1 The core network 

The core network (called EPC in SAE) is responsible for the overall control of the UE and estab- 
lishment of the bearers. The main logical nodes of the EPC are: 

• PDN Gateway (P-GW) 

• Serving Gateway (S-GW) 

• Mobility Management Entity (MME) 

In addition to these nodes, EPC also includes other logical nodes and functions such as the Home 

Subscriber Server (HSS) and the Policy Control and Charging Rules Function (PCRF). Since the 

EPS only provides a bearer path of a certain QoS, control of multimedia applications such as VoIP 

is provided by the IP Multimedia Subsystem (IMS), which is considered to be outside the EPS itself. 

The logical CN nodes are shown in Figure 1 and discussed in more detail below: 

• PCRF - The Policy Control and Charging Rules Function is responsible for policy control 
decision-making, as well as for controlling the flow-based charging functionalities in the Policy 
Control Enforcement Function (PCEF), which resides in the P-GW. The PCRF provides the 
QoS authorization (QoS class identifier [QCI] and bit rates) that decides how a certain data flow 
will be treated in the PCEF and ensures that this is in accordance with the user’s subscription 
profile. 

• HSS - The Home Subscriber Server contains users’ SAE subscription data such as the EPS-subscribed 
QoS profile and any access restrictions for roaming. It also holds information about the PDNs to 
which the user can connect. This could be in the form of an access point name (APN) (which 
is a label according to DNS naming conventions describing the access point to the PDN) or a PDN 
address (indicating subscribed IP address(es)). In addition the HSS holds dynamic information 
such as the identity of the MME to which the user is currently attached or registered. The HSS may 
also integrate the authentication center (AUC), which generates the vectors for authentication and 
security keys. 

• P-GW - The PDN Gateway is responsible for IP address allocation for the UE, as well as QoS 
enforcement and flow-based charging according to rules from the PCRF. It is responsible for the 
filtering of downlink user IP packets into the different QoS-based bearers. This is performed based 
on Traffic Flow Templates (TFTs). The P-GW performs QoS enforcement for guaranteed bit rate 
(GBR) bearers. It also serves as the mobility anchor for interworking with non-3GPP technologies 
such as CDMA2000 and WiMAX® networks. 

• S-GW - All user IP packets are transferred through the Serving Gateway, which serves as the 
local mobility anchor for the data bearers when the UE moves between eNodeBs. It also retains 
the information about the bearers when the UE is in the idle state (known as “EPS Connection 
Management — IDLE” [ECM-IDLE]) and temporarily buffers downlink data while the MME 
initiates paging of the UE to reestablish the bearers. In addition, the S-GW performs some 
administrative functions in the visited network such as collecting information for charging (for 
example, the volume of data sent to or received from the user) and lawful interception. It also 
serves as the mobility anchor for interworking with other 3GPP technologies such as general 
packet radio service (GPRS) and UMTS. 

• MME - The Mobility Management Entity (MME) is the control node that processes the signaling 
between the UE and the CN. The protocols running between the UE and the CN are known as 
the Non Access Stratum (NAS) protocols. 
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The main functions supported by the MME can be classified as: 

• Functions related to bearer management - This includes the establishment, maintenance and release 
of the bearers and is handled by the session management layer in the NAS protocol. 

• Functions related to connection management - This includes the establishment of the connection and 
security between the network and UE and is handled by the connection or mobility management 
layer in the NAS protocol layer. 

NAS control procedures are specified in [1] and are discussed in more detail in the following section. 

3.1.1 Non Access Stratum procedures 

The Non Access Stratum procedures, especially the connection management procedures, are fun- 
damentally similar to UMTS. The main change from UMTS is that EPS allows concatenation of 
some procedures to allow faster establishment of the connection and the bearers. 

The MME creates a UE context when a UE is turned on and attaches to the network. It assigns a unique 
short temporary identity termed the SAE Temporary Mobile Subscriber Identity (STMSI) to the UE that 
identifies the UE context in the MME. This UE context holds user subscription information downloaded 
from the HSS. The local storage of subscription data in the MME allows faster execution of procedures 
such as bearer establishment since it removes the need to consult the HSS every time. In addition, the UE 
context also holds dynamic information such as the list of bearers that are established and the terminal 
capabilities. 

To reduce the overhead in the E-UTRAN and processing in the UE, all UE-related information in 
the access network, including the radio bearers, can be released during long periods of data inactivity. 
This is the ECMdDLE state. The MME retains the UE context and the information about the 
established bearers during these idle periods. 

To allow the network to contact an ECM-IDLE UE, the UE updates the network as to its new location 
whenever it moves out of its current tracking area (TA); this procedure is called a tracking area 
update. The MME is responsible for keeping track of the user location while the UE is in ECM-IDLE. 

When there is a need to deliver downlink data to an ECM-IDLE UE, the MME sends a paging message 
to all the eNodeBs in its current TA, and the eNodeBs page the UE over the radio interface. On 
receipt of a paging message, the UE performs a Service Request procedure, which results in moving 
the UE to the ECM-CONNECTED state. UE-related information is thereby created in the E-UTRAN, 
and the radio bearers are reestablished. The MME is responsible for the reestablishment of the 
radio bearers and updating the UE context in the eNodeB. This transition between the UE states is 
called an idle-to-active transition. To speed up the idle-to-active transition and bearer establishment, 
EPS supports concatenation of the NAS and Access Stratum (AS) procedures for bearer activation. 
Some interrelationship between the NAS and AS protocols is intentionally used to allow procedures 
to run simultaneously rather than sequentially, as in UMTS. For example, the bearer establishment 
procedure can be executed by the network without waiting for the completion of the security procedure. 

Security functions are the responsibility of the MME for both signaling and user data. When a UE 
attaches with the network, a mutual authentication of the UE and the network is performed between 
the UE and the MME/HSS. This authentication function also establishes the security keys that are 
used for encryption of the bearers. 
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3.2 The access network 

The access network of LTE, E-UTRAN, 
simply consists of a network of eNodeBs, 
as illustrated in Figure 3. For normal 
user traffic (as opposed to broadcast), 
there is no centralized controller in 
E-UTRAN; hence the E-UTRAN 
architecture is said to be flat. 

The eNodeBs are normally intercon- 
nected with each other by means of an 
interface known as “XT’ and to the EPC 
by means of the SI interface — more 
specifically, to the MME by means of the 
Sl-MME interface and to the S-GW by 
means of the Sl-U interface. 


The protocols that run between the 
eNodeBs and the UE are known as the 
“AS protocols.” 

The E-UTRAN is responsible for all radio-related functions, which can be summarized briefly as: 

• Radio resource management (RRM) - This covers all functions related to the radio bearers, such 
as radio bearer control, radio admission control, radio mobility control, scheduling and dynamic 
allocation of resources to UEs in both uplink and downlink. 

• Header Compression - This helps to ensure efficient use of the radio interface by compressing 
the IP packet headers that could otherwise represent a significant overhead, especially for small 
packets such as VoIP. 

• Security - All data sent over the radio interface is encrypted. 

• Connectivity to the EPC - This consists of the signaling toward MME and the bearer path 
toward the S-GW. 

On the network side, all of these functions reside in the eNodeBs, each of which can be responsible for 
managing multiple cells. Unlike some of the previous second- and third-generation technologies, 
LTE integrates the radio controller function into the eNodeB. This allows tight interaction between the 
different protocol layers of the radio access network (RAN), thus reducing latency and improving 
efficiency. Such distributed control eliminates the need for a high-availability, processing-intensive 
controller, which in turn has the potential to reduce costs and avoid “single points of failure.” Fur- 
thermore, as LTE does not support soft handover there is no need for a centralized data-combining 
function in the network. 

One consequence of the lack of a centralized controller node is that, as the UE moves, the network 
must transfer all information related to a UE, that is, the UE context, together with any buffered data, 
from one eNodeB to another. Mechanisms are therefore needed to avoid data loss during handover. 
The operation of the X2 interface for this purpose is explained in more detail in Section 7. 


Figure 3. Overall E-UTRAN architecture 
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An important feature of the SI interface linking the access network to the CN is known as “Sl-flex.” 
This is a concept whereby multiple CN nodes (MME/S-GWs) can serve a common geographical 
area, being connected by a mesh network to the set of eNodeBs in that area. (See Section 6.) An 
eNodeB may thus be served by multiple MME/S-GWs, as is the case for eNodeB #2 in Figure 3. 

The set of MME/S-GW nodes that serves a common area is called an MME/S-GW pool, and the 
area covered by such a pool of MME/S-GWs is called a pool area. This concept allows UEs in the 
cell or cells controlled by one eNodeB to be shared between multiple CN nodes, thereby providing 
a possibility for load sharing and also eliminating single points of failure for the CN nodes. The UE 
context normally remains with the same MME as long as the UE is located within the pool area. 

3.3 Roaming architecture 

A network run by one operator in one country is known as a “public land mobile network (PLMN).” 
Roaming, where users are allowed to connect to PLMNs other than those to which they are directly 
subscribed, is a powerful feature for mobile networks, and LTE/SAE is no exception. A roaming user 
is connected to the E-UTRAN, MME and S-GW of the visited LTE network. However, LTE/SAE 
allows the P-GW of either the visited or the home network to be used, as shown in Figure 4- Using 
the home network’s P-GW allows the user to access the home operator’s services even while in a 
visited network. A P-GW in the visited network allows a “local breakout” to the Internet in the 
visited network. 


Figure 4. Roaming architecture for 3GPP accesses with P-GW in home network 



3.4 Interworking with other networks 

EPS also supports interworking and mobility (handover) with networks using other Radio Access 
Technologies (RATs), notably Global System for Mobile Communications (GSM), UMTS, 
CDMA2000 and WiMAX. The architecture for interworking with 2G and 3G GPRS/UMTS 
networks is shown in Figure 5. The S-GW acts as the mobility anchor for interworking with other 
3GPP technologies such as GSM and UMTS, while the P-GW serves as an anchor allowing seamless 
mobility to non-3GPP networks such as CDMA2000 or WiMAX. The P-GW may also support a Proxy 
Mobile Internet Protocol (PMIP)-based interface. More details of the radio interface procedures 
for interworking are specified in [3] and are also covered in Section 6.6.2. 
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Figure 5. Architecture for 3G UMTS interworking 
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4. Protocol architecture 

We outline here the radio protocol architecture of E-UTRAN. 

4.1 User plane 

An IP packet for a UE is encapsulated in an EPC-specific protocol and tunneled between the P-GW 
and the eNodeB for transmission to the UE. Different tunneling protocols are used across different 
interfaces. A 3GPP-specific tunneling protocol called the GPRS Tunneling Protocol (GTP) is used 
over the CN interfaces, SI and S5/S8. 1 

The E-UTRAN user plane protocol stack is shown in blue in Figure 6, consisting of the Packet 
Data Convergence Protocol (PDCP), Radio Link Control (RLC) and Medium Access Control 
(MAC) sublayers that are terminated in the eNodeB on the network side. The respective roles of 
each of these layers are explained in detail in Chapter 4 of [8]. 


Figure 6. The E-UTRAN user plane protocol stack 



LTE-Uu Sl-U S5/S8 SG 

UE eNodeB S-GW P-GW 


1 SAE also provides an option to use PMIP on S5/S8. More details on the MIP-based S5/S8 interface can be found in [3]. 
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4.1.1 Data handling during handover 

In the absence of any centralized controller node, data buffering during handover due to user 
mobility in the E-UTRAN must be performed in the eNodeB itself. Data protection during 
handover is a responsibility of the PDCP layer. The RLC and MAC layers both start afresh 
in a new cell after handover. 

4.2 Control plane 

The protocol stack for the control plane between the UE and MME is shown in Figure 7. The blue 
region of the stack indicates the AS protocols. The lower layers perform the same functions as for 
the user plane with the exception that there is no header compression function for the control plane. 


Figure 7. Control plane protocol stack 
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The Radio Resource Control (RRC) protocol is known as “layer 3” in the AS protocol stack. It is 
the main controlling function in the AS, being responsible for establishing the radio bearers and 
configuring all the lower layers using RRC signaling between the eNodeB and the UE. 

5. Quality of service and EPS bearers 

In a typical case, multiple applications may be running in a UE at any time, each one having different 
quality of service requirements. For example, a UE can be engaged in a VoIP call while at the same 
time browsing a web page or downloading an FTP file. VoIP has more stringent requirements for 
QoS in terms of delay and delay jitter than web browsing and FTP, while the latter requires a much 
lower packet loss rate. In order to support multiple QoS requirements, different bearers are set up 
within the Evolved Packet System, each being associated with a QoS. 

Broadly, bearers can be classified into two categories based on the nature of the QoS they provide: 

• Minimum guaranteed bit rate (GBR) bearers that can be used for applications such as VoIP. 
These have an associated GBR value for which dedicated transmission resources are permanently 
allocated (for example, by an admission control function in the eNodeB) at bearer establishment 
or modification. Bit rates higher than the GBR may be allowed for a GBR bearer if resources are 
available. In such cases, a maximum bit rate (MBR) parameter, which can also be associated 
with a GBR bearer, sets an upper limit on the bit rate that can be expected from a GBR bearer. 

• Non-GBR bearers that do not guarantee any particular bit rate. These can be used for applications 
such as web browsing or FTP transfer. For these bearers, no bandwidth resources are allocated 
permanently to the bearer. 
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In the access network, it is the responsibility of the eNodeB to ensure the necessary QoS for a bearer 
over the radio interface. Each bearer has an associated QCI, and an Allocation and Retention 
Priority (ARP). 

Each QCI is characterized by priority, packet delay budget and acceptable packet loss rate. The QCI 
label for a bearer determines how it is handled in the eNodeB. Only a dozen such QCIs have been 
standardized so that vendors can all have the same understanding of the underlying service char- 
acteristics and thus provide corresponding treatment, including queue management, conditioning 
and policing strategy. 

This ensures that an LTE operator can expect uniform traffic-handling behavior throughout the 
network regardless of the manufacturers of the eNodeB equipment. The set of standardized QCIs 
and their characteristics (from which the PCRF in an EPS can select) is provided in Table 1 (from 
Section 6.1.7 in [5]). The QCI table specifies values for the priority handling, acceptable delay budget 
and packet loss rate for each QCI label. 


Table 1. Standardized QCIs for LTE 


QCI 

RESOURCE 

TYPE 

PRIORITY 

PACKET DELAY PACKET ERROR EXAMPLE SERVICES 

BUDGET (MS) LOSS RATE 

1 

GBR 

2 

100 

io- 2 

Conversational voice 

2 

GBR 

4 

150 

io- 3 

Conversational video (live streaming) 

3 

GBR 

5 

300 

io- 6 

Non-conversational video (buffered streaming) 

4 

GBR 

3 

50 

IO 3 

Real-time gaming 

5 

Non-GBR 

1 

100 

io- 6 

IMS signaling 

6 

Non-GBR 

7 

100 

io- 3 

Voice, video (live streaming), interactive gaming 

7 

Non-GBR 

6 

300 

io- 6 

Video (buffered streaming) 

8 

Non-GBR 

8 

300 

io- 6 

TCP-based (for example, WWW, e-mail), chat, FTP, 






p2p file sharing, progressive video and others 

9 

Non-GBR 

9 

300 

IO 6 



The priority and packet delay budget (and to some extent the acceptable packet loss rate) from the 
QCI label determine the RLC mode configuration (see Section 4-3.1 of [8]) and how the scheduler 
in the MAC handles packets sent over the bearer (for example, in terms of scheduling policy, queue 
management policy and rate-shaping policy). For example, a packet with higher priority can be 
expected to be scheduled before a packet with lower priority. For bearers with a low acceptable loss 
rate, an acknowledged mode (AM) can be used within the RLC protocol layer to ensure that 
packets are delivered successfully across the radio interface. 

The ARP of a bearer is used for call admission control — that is, to decide whether or not the 
requested bearer should be established in case of radio congestion. It also governs the prioritization 
of the bearer for pre-emption with respect to a new bearer establishment request. Once successfully 
established, a bearer’s ARP does not have any impact on the bearer-level packet forwarding treatment 
(for example, for scheduling and rate control). Such packet forwarding treatment should be solely 
determined by the other bearer level QoS parameters such as QCI, GBR and MBR. 
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An EPS bearer has to cross multiple interfaces as shown in Figure 8 — the S5/S8 interface from 
the P-GW to the S-GW, the SI interface from the S-GW to the eNodeB, and the radio interface 
(also known as the “LTE-Uu interface”) from the eNodeB to the UE. Across each interface, the EPS 
bearer is mapped onto a lower layer bearer, each with its own bearer identity. Each node must keep 
track of the binding between the bearer IDs across its different interfaces. 

An S5/S8 bearer transports the packets of an EPS bearer between a P-GW and an S-GW. The S-GW 
stores a one-to-one mapping between an SI bearer and an S5/S8 bearer. The bearer is identified by 
the GTP tunnel ID across both interfaces. 


Figure 8. LTE/SAE bearer across the different interfaces 



Radio bearer 


SI bearer 


S5/S8 bearer 


The packets of an EPS bearer are transported by an SI bearer between an S-GW and an eNodeB, 
and by a radio bearer [6] between a UE and an eNodeB. An eNodeB stores a one-to-one mapping 
between a radio bearer ID and an SI bearer to create the mapping between the two. 

IP packets mapped to the same EPS bearer receive the same bearer-level packet forwarding treatment 
(for example, scheduling policy, queue management policy, rate shaping policy, RLC configuration). 
In order to provide different bearer-level QoS, a separate EPS bearer must therefore be established 
for each QoS flow. User IP packets must then be filtered into the appropriate EPS bearers. 

Packet filtering into different bearers is based on TFTs. The TFTs use IP header information such as 
source and destination IP addresses and Transmission Control Protocol (TCP) port numbers to filter 
packets such as VoIP from web-browsing traffic, so that each can be sent down the respective bearers 
with appropriate QoS. An Uplink TFT (UL TFT) associated with each bearer in the UE filters IP 
packets to EPS bearers in the uplink direction. A Downlink TFT (DL TFT) in the P-GW is a similar 
set of downlink packet filters. 

As part of the procedure by which a UE attaches to the network, the UE is assigned an IP address 
by the P-GW and at least one bearer is established. This is called the default bearer, and it remains 
established throughout the lifetime of the PDN connection in order to provide the UE with always-on 
IP connectivity to that PDN. The initial bearer-level QoS parameter values of the default bearer are 
assigned by the MME, based on subscription data retrieved from the HSS. The PCEF may change 
these values in interaction with the PCRF or according to local configuration. Additional bearers 
called dedicated bearers can also be established at any time during or after completion of the attach 
procedure. A dedicated bearer can be either a GBR or a non-GBR bearer (the default bearer always 
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has to be a non-GBR bearer since it is permanently established). The distinction between default 
and dedicated bearers should be transparent to the access network (for example, E-UTRAN). Each 
bearer has an associated QoS, and if more than one bearer is established for a given UE, then each 
bearer must also be associated with appropriate TFTs. These dedicated bearers could be established 
by the network, based for example on a trigger from the IMS domain, or they could be requested by 
the UE. The dedicated bearers for a UE may be provided by one or more P-GWs. 

The bearer-level QoS parameter values for dedicated bearers are received by the P-GW from the 
PCRF and forwarded to the S-GW. The MME only transparently forwards those values received 
from the S-GW over the Sll reference point (see Figure 5) to the E-UTRAN. 

5.1 Bearer establishment procedure 

This section describes a typical end-to-end bearer establishment procedure across the network nodes, 
as shown in Figure 9, using the functionality described in the above sections. When a bearer is 
established, the bearers across each of the interfaces discussed above are established. 

The PCRF sends a Policy Control and Charging (PCC) Decision Provision message indicating the 
required QoS for the bearer to the P-GW. The P-GW uses this QoS policy to assign the bearer-level 
QoS parameters. The P-GW then sends a Create Dedicated Bearer Request message including the 
QoS and UL TFT to be used in the UE to the S-GW. After the S-GW receives the Create Dedi- 
cated Bearer Request message, including bearer QoS, UL TFT and Sl-bearer ID, it forwards it to 
the MME (message 3 in Figure 9). 


Figure 9. An example message flow for a LTE/SAE bearer establishment 
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eNodeB 


MME 
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P-GW 


PCRF 


(1. PCC Decision Provision) 


2. Create Dedicated Bearer Request 
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4. Bearer Setup Request 


5. RRC Connection Reconfiguration 


6. RRC Connection Reconfiguration Complete 

7. Bearer Setup Response 

8. Create Dedicated Bearer Response 




9. Create Dedicated Bearer Response 

(10. Provision ACK) 

* 
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The MME then builds a set of session management configuration information including the UL TFT 
and the EPS bearer identity and includes it in the Bearer Setup Request message that it sends to the 
eNodeB (message 4 in Figure 9). Since the session management configuration is NAS information, 
it is sent transparently by the eNodeB to the UE. 


The LTE Network Architecture | Strategic White Paper 11 






The Bearer Setup Request also provides the QoS of the bearer to the eNodeB; this information is 
used by the eNodeB for call admission control and also to ensure the necessary QoS by appropriate 
scheduling of the user’s IP packets. The eNodeB maps the EPS bearer QoS to the radio bearer QoS 
and then signals an RRC Connection Reconfiguration message (including the radio bearer QoS, 
session management request and EPS radio bearer identity) to the UE to setup the radio bearer 
(message 5 in Figure 9). The RRC Connection Reconfiguration message contains all the configuration 
parameters for the radio interface. These are mainly for the configuration of the layer 2 (the PDCP, 
RLC and MAC parameters), but also contain the layer 1 parameters required for the UE to initialize 
the protocol stack. 

Messages 6 to 10 are the corresponding response messages to confirm that the bearers have been 
correctly set up. 

6. The E-IJTRAN network interfaces: SI interface 

The provision of self-optimizing networks (SONs) is one of the key objectives of LTE. Indeed, 
self-optimization of the network is a high priority for network operators as a tool to derive the best 
performance from the network in a cost-effective manner, especially in changing radio propagation 
environments. Hence SON has been placed as a cornerstone of the LTE system from the beginning 
and is the concept around which all SI and X2 procedures have been designed. 

The SI interface connects the eNodeB to the EPC. It is split into two interfaces, one for the control 
plane and the other for the user plane. The protocol structure for the SI and the functionality provided 
over SI are discussed in more detail below. 

6.1 Protocol structure over SI 

The protocol structure over SI is based on a full IP transport stack with no dependency on legacy 
SS7 2 network configuration as used in GSM or UMTS networks. This simplification provides one 
expected area of savings on operational expenditure when LTE networks are deployed. 

6.1.1 Control plane 

Figure 10 shows the protocol structure of the SI control plane, which is based on the well-known 
Stream Control Transmission Protocol / IP (SCTP/IP) stack. 

The SCTP protocol is well known for its advanced 
features inherited from TCP that ensure the required 
reliable delivery of the signaling messages. In addition it 
makes it possible to benefit from improved features such 
as the handling of multi-streams to implement transport 
network redundancy easily and avoid head-of-line blocking 
or multi-homing. (See IETF RFC 4960 [7].) 

An area of simplification in LTE (as compared to the 
UMTS Iu interface, for example) is the direct mapping of 
SI Application Protocol (Sl-AP) on top of SCTP. This 
results in a simplified protocol stack with no intermediate 
connection management protocol, since the individual 
connections are handled directly at the application layer. Multiplexing takes place between Sl-AP 
and SCTP whereby each stream of an SCTP association is multiplexed with the signaling traffic of 
multiple individual connections. 


Figure 10. SI control plane protocol stack 
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2 Signaling System #7 (SS7) is a communications protocol defined by the International Telecommunication Union Telecommunication 
Standardization Sector with a main purpose of setting up and tearing down telephone calls. Other uses include Short Message 
Service, number translation, prepaid billing mechanisms and many other services. 
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LTE has also built flexibility into the lower layer protocols, giving the operator full optionality 
regarding the choice of IP version and the data link layer. For example, this enables the operator to 
start deployment using IP version 4 with the data link tailored to the network deployment scenario. 

6.1.2 User plane 

Figure 11 gives the protocol structure of the SI user plane, based on the GTP/UDP5/IP stack, 
which is already well known from UMTS networks. 

One of the advantages of using GPRS Tunneling Protocol- Figure 11. SI -U user plane protocol stack 
User plane (GTP-U) is its inherent facility to identify 
tunnels and to facilitate intra-3GPP mobility. 

The IP version number and the data link layer have been 
left fully optional, as for the control plane stack. 

A transport bearer is identified by the GTP tunnel endpoints 
and the IP address (source Tunneling End ID [TEID]), 
destination TEID, source IP address, destination IP 
address). The S-GW sends downlink packets of a given 
bearer to the eNodeB IP address (received in Sl-AP) 
associated to that particular bearer. Similarly, the eNodeB sends upstream packets of a given bearer 
to the EPC IP address (received in Sl-AP) associated with that particular bearer. 

Vendor-specific traffic categories (for example, real-time traffic) can be mapped onto Differentiated 
Services (DiffServ) code points (for example, expedited forwarding) by network operations and 
maintenance (O&M) configuration to manage QoS differentiation between the bearers. 

6.2 Initiation over SI 

The initialization of the Sl-MME control plane interface starts with the identification of the MMEs 
to which the eNodeB must connect, followed by the setting up of the Transport Network Layer (TNL). 

With the support of the Sl-flex function in LTE, an eNodeB must initiate an SI interface toward 
each MME node of the pool area to which it belongs. The list of MME nodes of the pool together with 
an initial corresponding remote IP address can be directly configured in the eNodeB at deployment 
(although other means may also be used). The eNodeB then initiates the TNL establishment with 
that IP address. Only one SCTP association is established between one eNodeB and one MME. 

During the establishment of the SCTP association, the two nodes negotiate the maximum number 
of streams that will be used over that association. However, multiple pairs of streams are typically used 
in order to avoid the head-of-line blocking issue mentioned above. (Note that a stream is unidirec- 
tional and therefore pairs must be used.) Among these pairs of streams, one must be reserved by the 
two nodes for the signaling of the common procedures (that is, those that are not specific to one UE). 
The other streams are used for the sole purpose of the dedicated procedures (that is, those that are 
specific to one UE). 

Once the TNL has been established, some basic application-level configuration data for the system 
operation is automatically exchanged between the eNodeB and the MME through an SI Setup proce- 
dure initiated by the eNodeB. This procedure constitutes one example of a network self-configuration 
process provided in LTE to reduce the configuration effort for network operators compared to the 
more usual manual configuration procedures of earlier systems. 
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An example of basic application data that can be automatically configured through the SI Setup 
procedure is the tracking area identities, which correspond to the zones in which UEs will be paged. 
Their mapping to eNodeBs must remain consistent between the E-UTRAN and the EPC. Once the 
tracking area identities have been configured within each eNodeB, they are sent automatically to all 
the relevant MME nodes of the pool area within the SI Setup Request message. The same applies 
for the broadcast list of PLMNs that is used when a network is being shared by several operators 
(each having its own PLMN-ID that needs to be broadcast for the UEs to recognize it). This saves 
a significant amount of configuration effort in the CN, avoids the risk of human error, and ensures 
that the E-UTRAN and EPC configurations regarding tracking areas and PLMNs are aligned. 


Once the SI Setup procedure has been completed, the SI interface is operational. 


6.3 Context management over SI 

Within each pool area, a UE is associated with one particular MME for all its communications during 
its stay in this pool area. This creates a context in this MME for the UE. This particular MME is 
selected by the NAS Node Selection Function (NNSF) in the first eNodeB from which the UE 
entered the pool. 


Whenever the UE becomes active (that is, makes a transition 
from idle to active mode) under the coverage of a particular 
eNodeB in the pool area, the MME provides the UE context 
information to this eNodeB using the Initial Context Setup 
Request message. (See Figure 12.) This enables the eNodeB 
in turn to create a context and manage the UE for the 
duration of its activity in active mode. 


Figure 12. Initial Context Setup procedure 
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Even though the setup of bearers is otherwise relevant 
to a dedicated bearer management procedure described 
below, the creation of the eNodeB context by the Initial 

Context Setup procedure also includes the creation of one or several bearers including the default 
bearer. 


At the next transition back to idle mode following a UE Context Release Command message sent from 
the MME, the UE context in the eNodeB is erased and only the UE context in the MME remains. 

6.4 Bearer management over SI 

LTE uses dedicated procedures independently covering the setup, modification and release of bearers. 
For each bearer requested to be setup, the transport layer address and the tunnel endpoint are provided 
to the eNodeB in the Bearer Setup Request message to indicate the termination of the bearer in the 
S'GW where uplink user plane data must be sent. Conversely, the eNodeB indicates in the Bearer 
Setup Response message the termination of the bearer in the eNodeB where the downlink user plane 
data must be sent. For each bearer, the QoS parameters (see Section 5 above) requested for the bearer 
are also indicated. Independently of the standardized QCI values, it is also still possible to use extra 
proprietary QCI values for the fast introduction of new services if vendors and operators agree upon them. 

6.5 Paging over SI 

As mentioned in Section 6.3, in order to reestablish a connection toward a UE in idle mode, the 
MME distributes a paging request to the relevant eNodeBs based on the tracking areas where the 
UE is expected to be located. When it receives the Paging Request message, the eNodeB sends 
a page over the radio interface in the cells that are contained within one of the tracking areas 
provided in that message. 
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The UE is normally paged using its S-TMSI. The Paging Request message also contains a UE iden- 
tity index value in order for the eNodeB to calculate the paging occasions at which the UE will 
switch on its receiver to listen for paging messages. (See Section 3.4 of [8].) 

6.6 Mobility over SI 

LTE/SAE supports mobility within LTE/SAE as well as mobility to other systems using both 3GPP 
and non-3GPP technologies. The mobility procedures over the radio interface are described in 
Section 3.2 of [8]. These mobility procedures also involve the network interfaces. The sections 
below discuss the procedures over SI to support mobility. 

6.6.1 Intra-LTE mobility 

There are two types of handover procedure in LTE for UEs in active mode: the SI and X2 handover 
procedures. 

For intra-LTE mobility, that is, mobility within the LTE system, the X2-handover procedure is normally 
used for inter-eNodeB handover (described in Section 7.3). However, when there is no X2 interface 
between the two eNodeBs, or if the source eNodeB has been configured to initiate handover towards 
a particular target eNodeB through the SI interface, then an Sl-handover will be triggered. 

The Sl-handover procedure, shown in Figure 13, has been designed in a similar way to the UMTS 
Serving Radio Network Subsystem (SRNS) relocation procedure: it consists of a preparation phase, 
where the CN resources are prepared at the target side (steps 2 to 8), followed by an execution phase 
(steps 8 to 12) and a completion phase (after step 13). 


Figure 13. Si-based handover procedure 
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Compared to UMTS, the main difference is the introduction of the Status Transfer message sent 
by the source eNodeB (steps 10 and 11). This message has been added in order to carry some PDCP 
status information that is needed at the target eNodeB in cases when PDCP status preservation 
applies for the Sl-handover (see Section 4-2.4 of [8]); this is in alignment with the information that 
is sent within the X2 Status Transfer message used for the X2-handover. (See below.) As a result of 
this alignment, the handling of the handover by the target eNodeB as seen from the UE is exactly 
the same, regardless of the type of handover (SI or X2) being used. 

The Status Transfer procedure is assumed to be triggered in parallel with the start of data forward- 
ing after the source eNodeB has received the handover command message from the source MME. 
This data forwarding can be either direct or indirect, depending on the availability of a direct path 
for the user plane data between the source eNodeB and the target eNodeB. 

The Handover Notify message (step 13), which is sent later by the target eNodeB when the arrival 
of the UE at the target side is confirmed, is forwarded by the MME to trigger the update of the path 
switch in the S-GW toward the target eNodeB. In contrast to the X2-handover, the message is not 
acknowledged and the resources at the source side are released later upon reception of a Release Resource 
message directly triggered from the source MME (step 17 in Figure 13). 

6.6.2 Inter-Radio Access Technology mobility 

One key element of the design of the first release of LTE is the need to co-exist with other technologies. 

For mobility from LTE toward UMTS, the handover process can reuse the Sl-handover procedures 
described above, with the exception of the Status Transfer message, which is not needed at steps 10 
and 11 since no PDCP context is continued. 

For mobility toward CDMA2000, Figure 14. Uplink SI CDMA2000 tunneling procedure 

dedicated uplink and downlink 
procedures have been introduced in 
LTE. They essentially aim at tunneling 
the CDMA2000 signaling between 
the UE and the CDMA2000 system 
over the SI interface, without being 
interpreted by the eNodeB on the 
way. The Uplink SI CDMA2000 
Tunneling message shown in Figure 14 also includes the Radio Access Technology (RAT) type in 
order to identify the CDMA2000 RAT with which the tunneled CDMA2000 message is associated 
in order for the message to be routed to the correct node within the CDMA2000 system. 

6.7 Load management over SI 

Three types of load management procedures apply over SI: a normal load balancing procedure to 
distribute the traffic, an overload procedure to overcome a sudden peak in the loading and a load 
rebalancing procedure to partially/fully offload an MME. 

The MME load balancing procedure aims to distribute the traffic to the MMEs in the pool evenly 
according to their respective capacities. To achieve this goal, the procedure relies on the normal 
NNSF present in each eNodeB as part of the Sl-flex function. (See Section 6.3.) Provided that suit- 
able weight factors corresponding to the capacity of each MME node are available in the eNodeBs 


eNodeB 


MME 


Uplink SI CDMA2000 Tunneling 
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beforehand, a weighted NNSF done by each and every eNodeB in the network normally achieves a 
statistically balanced distribution of load among the MME nodes without further action. However, 
specific actions are still required for some particular scenarios: 

• If a new MME node is introduced (or removed), it may be necessary temporarily to increase (or 
decrease) the weight factor normally corresponding to the capacity of this node in order to make 
it catch more (or less) traffic at the beginning until it reaches an adequate level of load. 

• In case of an unexpected peak in the loading, an Overload message can be sent over the SI interface 
by the overloaded MME. When received by an eNodeB, this message calls for a temporary restric- 
tion of a certain type of traffic. An MME can adjust the reduction of traffic it desires by defining 
the number of eNodeBs to which it sends the Overload message and by defining the types of 
traffic subject to restriction. 

• Finally, if the MME wants to rapidly force the offload of some or all of its UEs, it will use the 
rebalancing function. This function forces the UEs to reattach to another MME by using a 
specific “cause value” in the UE Release Command SI message. In a first step it applies to idle 
mode UEs and in a second step it may also apply to UEs in connected mode (if full MME offload 
is desired, for example, for maintenance reasons). 


7. The E-UTRAN network interfaces: X2 interface 

The X2 interface is used to interconnect eNodeBs. The protocol structure for the X2 interface and 
the functionality provided over X2 are discussed below. 

7.1 Protocol structure over X2 

The control and user plane protocol stacks over the X2 interface, shown in figures 15 and 16 respec- 
tively, are the same as those for the SI interface, with the exception that X2-AP is substituted for 
Sl-AP. This also reaffirms that the choice of the IP version and the data link layer are fully optional. 

The use of the same protocol structure over both interfaces provides advantages such as simplifying 
the data forwarding operation. 


Figure 15. X2 signaling bearer protocol stack 


Figure 16. Transport Network Layer for data streams over X2 
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7.2 Initiation over X2 

The X2 interface may be established between one eNodeB and some of its neighbor eNodeBs in 
order to exchange signaling information when needed. However, a full mesh is not mandated in an 
E-UTRAN network. Two types of information may typically need to be exchanged over X2 to drive 
the establishment of an X2 interface between two eNodeBs: load- or interference-related information 
(see Section 7.4) and handover-related information (see mobility in Section 7.3). 
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Because these two types of information are fully independent of one another, it is possible that an X2 
interface may be present between two eNodeBs for the purpose of exchanging load or interference 
information, even though the X2-handover procedure is not used to handover UEs between those 
eNodeBs. In such a case, the Sl-handover procedure is used instead. 

The initialization of the X2 interface starts with the identification of a suitable neighbor followed by 
the setting up of the TNL. 

The identification of a suitable neighbor may be done by configuration or alternatively by a function 
known as the automatic neighbor relation function (ANRF). This function makes use of the UEs 
to identify the useful neighbor eNodeBs: an eNodeB may ask a UE to read the global cell identity 
from the broadcast information of another eNodeB for which the UE has identified the physical 
cell identity (PCI) during the new cell identification procedure. (See Section 7.2 of [8].) The ANRF 
is another example of a SON process introduced successfully in LTE. Through this self-optimizing 
process, UEs and eNodeB measurements are used to auto-tune the network. 

Once a suitable neighbor has been identified, the initiating eNodeB can set up the TNL using the 
X2 IP address of this neighbor, either as retrieved from the network or locally configured. In particular, 
a SON-configuration dedicated procedure over SI termed the eNB Configuration Transfer procedure 
has been designed to enable the initiating eNodeB to directly request over the SI interface the X2 
IP address of a discovered neighbor eNodeB to be used for X2 establishment. This network solution 
through the SI interface may avoid the need for an operator to use other more complex network 
solutions such as the deployment of DNS servers. 

After the TNL has been set up, the initiating eNodeB must trigger the X2 Setup procedure. This 
procedure enables an automatic exchange of application level configuration data relevant to the 
X2 interface, similar to the SI Setup procedure already described in Section 6.2. For example, each 
eNodeB reports to a neighbor eNodeB, using the X2 Setup Request message, information about each 
cell it manages, such as the cell’s physical identity, the frequency band, the tracking area identity 
and/or the associated PLMNs. 

This automatic data exchange in the X2 Setup procedure is also the core of another SON feature: 
the automatic self-configuration of the PCIs. Under this new SON feature, the O&M system can 
provide the eNodeBs with either a list of possible PCI values to use or a specific PCI value. In the 
first case, in order to avoid collisions, the eNodeB should use a PCI that is not already used in its 
neighborhood. Because the PCI information is included in the LTE X2 Setup procedure, while de- 
tecting a neighbor cell by the ANR function, an eNodeB can also discover all the PCI values used 
in the neighborhood of that cell and consequently eliminate those values from the list of suitable 
PCIs to start with. 

Once the X2 Setup procedure has been completed, the X2 interface is operational. 

7.3 Mobility over X2 

Handover through the X2 interface is triggered by default for intra-LTE mobility unless there is 
no X2 interface established or the source eNodeB is configured to use Sl-handover instead. The 
X2-handover procedure is illustrated in Figure 17. Like Sl-handover, it is also composed of a 
preparation phase (steps 4 to 6), an execution phase (steps 7 to 9) and a completion phase (after step 9). 
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The key features of X2-handover for intra-LTE handover are: 

• The handover is directly performed between two eNodeBs, making the preparation phase quick. 

• Data forwarding may be operated per bearer in order to minimize data loss. 

• The MME is only informed at the end of the handover procedure when the handover is 
successful, in order to trigger the path switch. 

• The release of resources at the source side is directly triggered from the target eNodeB. 

For those bearers requiring in-sequence delivery of packets, the Status Transfer message (step 8) 
provides the sequence number (SN) and the Hyper Frame Number (HFN) that the target eNodeB 
should assign to the first packet with no SN yet assigned that it must deliver. This first packet can 
either be one received over the target SI path or one received over X2, if data forwarding over X2 
is used. (See below.) When the source eNodeB sends the Status Transfer message, it freezes its trans- 
mitter/receiver status, that is, it stops assigning PDCP SNs to downlink packets and stops delivering 
uplink packets to the EPC. 

Mobility over X2 can be categorized according to its resilience to packet loss: the handover can be 
termed “seamless” if it minimizes the interruption time during the move of the UE or “lossless” if 
it tolerates no loss of packets at all. These two modes use data forwarding of user plane downlink 
packets. The source eNodeB may decide to operate one of these two modes on a per-EPS-bearer 
basis, based on the QoS received over SI for this bearer (see Section 6.4) and the service at stake. 

7.3.1 Seamless handovers 

If the source eNodeB selects the seamless mode for one bearer, it proposes to the target eNodeB in 
the Handover Request message to establish a GTP tunnel to operate the downlink data forwarding. 
If the target eNodeB accepts, it indicates in the Handover Request ACK message the tunnel end- 
point where the forwarded data is expected to be received. The tunnel endpoint may be different 
from the one set up as the termination point of the new bearer established over the target SI. 


Figure 17. X2-based handover procedure 
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Upon receipt of the Handover Request ACK message, the source eNodeB can start forwarding the 
freshly arriving data over the source SI path toward the indicated tunnel endpoint in parallel to 
sending the handover trigger to the UE over the radio interface. The forwarded data is thus available 
at the target eNodeB to be delivered to the UE as early as possible. 

When forwarding is in operation and in-sequence delivery of packets is required, the target eNodeB 
is assumed to first deliver the packets forwarded over X2 before delivering the ones received over the 
target SI path, once the SI path switch has been done. The end of the forwarding is signaled over 
X2 to the target eNodeB by the reception of “special GTP packets” that the S-GW has inserted 
over the source SI path just before switching this SI path; these are then forwarded by the source 
eNodeB over X2 like any other regular packets. 

7.3.2 Lossless handovers 

If the source eNodeB selects the lossless mode for one bearer, it will additionally forward over 
X2 those user plane downlink packets that it has PDCP-processed but that are still buffered locally 
because they have not yet been delivered and acknowledged by the UE. These packets are forwarded 
together with their assigned PDCP SN included in a GTP extension header field. They are sent over 
X2 prior to the fresh arriving packets from the source SI path. The same mechanisms described 
above for the seamless handover are used for the GTP tunnel establishment. The end of forward- 
ing is also handled in the same way, since in-sequence packet delivery applies to lossless handovers. 

In addition, the target eNodeB must ensure that all the packets, including the ones received with 
sequence number over X2, are delivered in sequence to the target side. Further details of seamless 
and lossless handover are described in Section 4-2 of [8]. 

A new feature in LTE is the optimization of the radio by selective retransmission. When lossless 
handover is used, the target eNodeB may not deliver over the radio interface some of the forwarded 
downlink packets received over X2 if it is informed by the UE that these packets have already been 
received at the source side. This is called downlink selective retransmission. 

Similarly in the uplink, the target eNodeB may not wish the UE to retransmit packets already received 
earlier at the source side by the source eNodeB, for example, to avoid wasting radio resources. To use 
uplink selective retransmission, the source eNodeB forwards the user plane uplink packets that it has 
received out of sequence to the target eNodeB, over a new GTP tunnel. The target eNodeB must first 
request the source eNodeB to establish the new forwarding tunnel by including a GTP tunnel end- 
point where it expects the forwarded uplink packets to be received in the Handover Request ACK 
message. If possible, the source eNodeB then indicates in the Status Transfer message for this bearer, 
the list of SNs corresponding to the expected forwarded packets. This list helps the target eNodeB 
inform the UE earlier of the packets that are not to be retransmitted, making the overall uplink 
selective retransmission scheme faster . 

7.3.3 Multiple preparation 

Another new feature of the LTE handover procedure compared to UMTS is multiple preparation. 
This feature enables the source eNodeB to trigger the handover preparation procedure towards 
multiple candidate target eNodeBs. Even though only one of the candidates is indicated as target to 
the UE, this makes recovery faster in case the UE fails to attach to the target and connects to one 
of the other prepared candidate eNodeBs instead. The source eNodeB receives only one Release 
Resource message from the final selected eNodeB. 
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Regardless of whether multiple or single preparation is used, the handover can be canceled during 
or after the preparation phase. If the multiple preparation feature is used, it is for example recom- 
mended that upon reception of the Release Resource message the source eNodeB triggers a Cancel 
procedure toward each of the non-selected prepared eNodeBs. 

7.4 Load and interference management over X2 

The exchange of load information between eNodeBs is of key importance in the flat architecture 
used in LTE, as there is no central RRM node as was the case, for example, in UMTS with the Radio 
Network Controller (RNC). The exchange of load information falls into two categories depending 
on the purpose it serves. 

• The exchange of load information can be used for the X2 load balancing process, in which case 
the relevant frequency of exchange is rather low (in the order of seconds); 

• The exchange of load information can be used to optimize some RRM processes, such as in- 
terference coordination (as discussed in Section 12.5 of [8]), in which case the frequency of 
exchange is rather high (in the order of tens of milliseconds). 

7.4.1 Load balancing 

Like the ANRF SON function described in Section 7.2, load balancing is another aspect of SON 
built into the design of LTE. The objective of load balancing is to counteract local traffic load 
imbalance between neighboring cells with the aim of improving the overall system capacity. One 
solution is to optimize the cell reselection/handover parameters (such as thresholds and hysteresis) 
between neighboring cells autonomously upon detection of an imbalance. 

In order to detect an imbalance, itis necessary to compare the load of the cells and therefore to 
exchange information about them between neighboring eNodeBs. The cell load information 
exchanged can be of different types: radio measurements corresponding to the usage of physical 
resource blocks, possibly partitioned into real-time and non-real-time traffic; or generic measure- 
ments representing non-radio-related resource usage such as processing or hardware occupancy. 

A client-server mechanism is used for the load information exchange: the Resource Status Response 
and Update messages are used to report the load information over the X2 interface between a request- 
ing eNodeB (client) and the eNodeBs that have subscribed to this request (servers). The reporting 
of the load is periodic and according to the periodicity expressed in the Resource Status Request 
message that triggered the procedure. 

7.4.2 Interference management 

A separate load indication procedure is used over the 
X2 interface for the exchange of load information related 
to interference management as shown in Figure 18. As 
these measurements have direct influence on some RRM 
real-time processes, the frequency of reporting using this 
procedure may be high. 

For the uplink interference, two indicators can be provided 

within the load indication message: a “High Interference Indicator” and an “Overload Indicator.” 

The usage of these indicators is explained in Section 12.5 of [8]. 


Figure 18. Load indication over X2 interface 
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7.5 UE historical information over X2 

Historical UE information constitutes another example of a feature designed to support SON built 
into the design of LTE. It is embedded within the X2 -handover procedure. Historical UE information 
consists, for example, of the last few cells visited by the UE, together with the time spent in each 
one. This information is propagated from one eNodeB to another within the Handover Request 
messages and can be used to determine the occurrence of ping-pong between two or three cells for 
instance. The length of the history information can be configured for more flexibility. 

More generally, the historical UE information consists of some RRM information that is passed 
from the source eNodeB to the target eNodeB within the Handover Request message to assist the 
RRM management of a UE or of a cell. The information can be partitioned into two types: 

• UE RRM-related information, passed over X2 within the RRC transparent container 

• Cell RRM-related information, passed over X2 directly as an information element of the X2-AP 
Handover Request message itself 


8. Summary 

In this paper the mechanisms by which the Evolved Packet System provides user equipment with 
IP connectivity to the packet data network have been outlined. 

It has been shown how the EPS supports multiple data flows with different quality of service per UE 
for applications that need guaranteed delay and bit rate such as VoIP as well as best effort applications 
such as web browsing. 

Further, an overview of the EPS network architecture has been presented, including the functions 
provided by the E-UTRAN access network and the evolved packet CN. It can be seen that the concept 
of EPS bearers, together with their associated QoS attributes, provide a powerful tool for the provi- 
sion of a variety of simultaneous services to the end user. 

From the perspective of the network operator, the LTE system breaks new ground in terms of its 
degree of support for self-optimization and self-configuration of the network through the X2, SI 
and Uu interfaces, to facilitate deployment. 


9. Abbreviations 

3GPP 

Third-Generation Partnership Project 

GPRS 

general packet radio service 

AM 

acknowledged mode 

GSM 

Global System for Mobile 

ANRF 

automatic neighbor relation function 


Communications 

AP 

Application Protocol 

GTP 

GPRS Tunneling Protocol 

APN 

access point name 

GTP-U 

GPRS Tunneling Protocol-User plane 

ARP 

Allocation and Retention Priority 

HFN 

Hyper Frame Number 

AS 

Access Stratum 

HSS 

Flome Subscriber Server 

AUC 

authentication center 

IETF 

Internet Engineering Task Force 

CN 

core network 

IMS 

IP Multimedia Subsystem 

DiffServ 

Differentiated Services 

IP 

Internet Protocol 

DL TFT 

Downlink TFT 

LTE 

Long Term Evolution 

DNS 

Domain Name System 

MAC 

Medium Access Control 

ECM 

EPS Connection Management 

MBR 

maximum bit rate 

EPC 

Evolved Packet Core 

MME 

Mobility Management Entity 

EPS 

Evolved Packet System 

NAS 

Non Access Stratum 

eNodeB 

Evolved NodeB 

NNSF 

NAS Node Selection Function 

E-UTRAN 

Evolved UTRAN 

O&M 

operation and maintenance 

GBR 

guaranteed bit rate 

PCC 

Policy Control and Charging 
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PCEF 

Policy Control Enforcement Function 

SCTP 

Stream Control Transmission Protocol 

PCI 

physical cell identity 

S-GW 

Serving Gateway 

PCRF 

Policy Control and Charging Rules Function 

SN 

sequence number 

PDCP 

Packet Data Convergence Protocol 

SON 

self-optimizing networks 

PDN 

packet data network 

SRNS 

Serving Radio Network Subsystem 

P-GW 

PDN Gateway 

S-TMSI 

SAE Temporary Mobile Subscriber Identity 

PLMN 

public land mobile network 

TA 

tracking area 

PMIP 

Proxy Mobile Internet Protocol 

TCP 

Transmission Control Protocol 

QCI 

QoS class identfier 

TEID 

Tunneling End ID 

QoS 

quality of service 

TFT 

Traffic Flow Template 

RAN 

radio access network 

TNF 

Transport Network Layer 

RAT 

Radio Access Technology 

LIE 

user equipment 

RFC 

Radio Fink Control 

UL TFT 

Uplink TFT 

RRC 

Radio Resource Control 

UMTS 

Universal Mobile Telecommunications System 

RRM 

Radio Resource Management 

UTRAN 

UMTS Terrestrial Radio Access Network 

SAE 

System Architecture Evolution 

VoIP 

Voice over IP 


The list above covers the abbreviations used in this paper. A comprehensive list of abbreviations relevant to LTE, together with concise 
explanations of each, can be found in [9]. 


10. Contacts 


For more information on Alcatel-Lucent’s LTE solution, please visit www.alcatel-lucent.com or 
contact your Customer Team representative. 

You can also contact Alcatel-Lucent Public Relations: 

Christine De Monfreid 
Public Relations 

Christine.De_Monfreid@alcatel-lucent.fr 
+33 1 3077 5914 
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